Testing a software interface for a streaming hardware device

ABSTRACT

Embodiments of the disclosure relate to testing a software interface for a streaming hardware device through simulation. Methods include receiving, by a processor, a data manipulation request and a data segment associated with the data manipulation request and generating, by the software interface, an input data stream comprising control information and the data segment. The method also includes transmitting the input data stream to a simulation device and generating, by the simulation device, an output data stream in response to the input data stream, the output data stream including a delineator, control data, a manipulated data segment and a trailing delineator. The simulation device is configured to simulate the operation of the streaming hardware device by performing the data manipulation request.

BACKGROUND

The present invention relates to interfaces for hardware devices, andmore specifically, to methods and systems for testing a softwareinterface for a streaming hardware device through simulation.

Recently, the use of special purpose hardware devices for performingprocessor intensive functions has been increasing. These hardwaredevices may be used for data manipulation operations, such as datacompression, encoding, or the like either in a single operation or in astreaming model where multiple requests are related. These streaminghardware devices, such as data manipulation devices, often havedifferent performance attributes, such as speed and latency, than ageneral processor performing similar operations in pure software. Forexample, an increased overhead may be incurred in communicating with astreaming hardware device as compared with a general processor.

In general, in order for the streaming hardware devices to be used by aprocessor a software interface is required. The software interfaceallows the processor and applications to utilize the streaming hardwaredevices to perform processor intensive functions. As the use ofstreaming hardware devices for applications continues to increase, thesoftware interfaces that will exploit these devices need to be tested.

SUMMARY

Embodiments include a computer system for testing a software interfacefor a streaming hardware device through simulation. The computer systemincludes a processor configured to execute a method including receiving,by a processor, a data manipulation request and a data segmentassociated with the data manipulation request and generating, by thesoftware interface, an input data stream comprising control informationand the data segment. The method also includes transmitting the inputdata stream to a simulation device and generating, by the simulationdevice, an output data stream in response to the input data stream, theoutput data stream including a delineator, control data, a manipulateddata segment and a trailing delineator. The simulation device isconfigured to simulate the operation of the streaming hardware device byperforming the data manipulation request.

Additional features and advantages are realized through the techniquesof the present invention. Other embodiments and aspects of the inventionare described in detail herein and are considered a part of the claimedinvention. For a better understanding of the invention with theadvantages and the features, refer to the description and to thedrawings.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The subject matter which is regarded as the invention is particularlypointed out and distinctly claimed in the claims at the conclusion ofthe specification. The forgoing and other features, and advantages ofthe invention are apparent from the following detailed description takenin conjunction with the accompanying drawings in which:

FIG. 1 illustrates a block diagram of a computer system for use inpracticing the teachings herein;

FIG. 2 illustrates a block diagram of a system for testing a softwareinterface for a streaming hardware device in accordance with anexemplary embodiment;

FIG. 3A illustrates a block diagram of a data stream between a streaminghardware device and a software interface in accordance with an exemplaryembodiment;

FIG. 3B illustrates a block diagram of a data stream between asimulation device and a software interface in accordance with anexemplary embodiment;

FIG. 3C illustrates a block diagram of a data stream between asimulation device and a software interface in accordance with anexemplary embodiment;

FIG. 3D illustrates a block diagram of a data stream between asimulation device and a software interface in accordance with anexemplary embodiment;

FIG. 3E illustrates a block diagram of a data stream between asimulation device and a software interface in accordance with anexemplary embodiment;

FIG. 4 illustrates a flow diagram of a method for testing a softwareinterface for a streaming hardware device through simulation inaccordance with an exemplary embodiment; and

FIG. 5 illustrates a state diagram illustrating the operation of asimulation device in accordance with an exemplary embodiment.

DETAILED DESCRIPTION

In accordance with exemplary embodiments, a software interface isconfigured to facilitate interaction between a processor and a streaminghardware device. The software interface permits the streaming hardwaredevice to be transparently integrated into a computer system and toperform processing for existing workloads and applications. In order tominimize the development time of both the software interface and thestreaming hardware device, testing of the software interface may beperformed through simulation while the development of the streaminghardware device is underway. In exemplary embodiments, simulation of astreaming hardware device provides a similar set of functions as thestreaming hardware device and manipulates test data in a way whereautomated test cases can validate that the data generated by thesoftware interface is correct.

FIG. 1 illustrates a block diagram of a computer system 100 for use inpracticing the teachings herein. The methods described herein can beimplemented in hardware, software (e.g., firmware), or a combinationthereof. In an exemplary embodiment, the methods described herein areimplemented in hardware, and may be part of the microprocessor of aspecial or general-purpose digital computer, such as a personalcomputer, workstation, minicomputer, or mainframe computer. The computersystem 100 therefore includes general-purpose computer 101.

In an exemplary embodiment, in terms of hardware architecture, as shownin FIG. 1, the computer 101 includes a processor 105, memory 110 coupledto a memory controller 115, and one or more input and/or output (I/O)devices 140, 145 (or peripherals) that are communicatively coupled via alocal input/output controller 135. The input/output controller 135 canbe, for example but not limited to, one or more buses or other wired orwireless connections, as is known in the art. The input/outputcontroller 135 may have additional elements, which are omitted forsimplicity, such as controllers, buffers (caches), drivers, repeaters,and receivers, to enable communications. Further, the local interfacemay include address, control, and/or data connections to enableappropriate communications among the aforementioned components.

The processor 105 is a hardware device for executing hardwareinstructions or software, particularly that stored in memory 110. Theprocessor 105 can be any custom made or commercially availableprocessor, a central processing unit (CPU), an auxiliary processor amongseveral processors associated with the computer 101, a semiconductorbased microprocessor (in the form of a microchip or chip set), a macroprocessor, or generally any device for executing instructions. Theprocessor 105 includes a cache 170, which may include, but is notlimited to, an instruction cache to speed up executable instructionfetch, a data cache to speed up data fetch and store, and a translationlookaside buffer (TLB) used to speed up virtual-to-physical addresstranslation for both executable instructions and data. The cache 170 maybe organized as a hierarchy of more cache levels (L1, L2, etc.).

The memory 110 can include any one or combination of volatile memoryelements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM,etc.)) and nonvolatile memory elements (e.g., ROM, erasable programmableread only memory (EPROM), electronically erasable programmable read onlymemory (EEPROM), programmable read only memory (PROM), tape, compactdisc read only memory (CD-ROM), disk, diskette, cartridge, cassette orthe like, etc.). Moreover, the memory 110 may incorporate electronic,magnetic, optical, and/or other types of storage media. Note that thememory 110 can have a distributed architecture, where various componentsare situated remote from one another, but can be accessed by theprocessor 105.

The instructions in memory 110 may include one or more separateprograms, each of which comprises an ordered listing of executableinstructions for implementing logical functions. In the example of FIG.1, the instructions in the memory 110 include a suitable operatingsystem (OS) 111. The operating system 111 essentially controls theexecution of other computer programs and provides scheduling,input-output control, file and data management, memory management, andcommunication control and related services.

In an exemplary embodiment, a conventional keyboard 150 and mouse 155can be coupled to the input/output controller 135. Other output devicessuch as the I/O devices 140, 145 may include input devices, for examplebut not limited to a printer, a scanner, microphone, and the like.Finally, the I/O devices 140, 145 may further include devices thatcommunicate both inputs and outputs, for instance but not limited to, anetwork interface card (NIC) or modulator/demodulator (for accessingother files, devices, systems, or a network), a radio frequency (RF) orother transceiver, a telephonic interface, a bridge, a router, and thelike. The system 100 can further include a display controller 125coupled to a display 130. In an exemplary embodiment, the system 100 canfurther include a network interface 160 for coupling to a network 165.The network 165 can be an IP-based network for communication between thecomputer 101 and any external server, client and the like via abroadband connection. The network 165 transmits and receives databetween the computer 101 and external systems. In an exemplaryembodiment, network 165 can be a managed IP network administered by aservice provider. The network 165 may be implemented in a wirelessfashion, e.g., using wireless protocols and technologies, such as WiFi,WiMax, etc. The network 165 can also be a packet-switched network suchas a local area network, wide area network, metropolitan area network,Internet network, or other similar type of network environment. Thenetwork 165 may be a fixed wireless network, a wireless local areanetwork (LAN), a wireless wide area network (WAN) a personal areanetwork (PAN), a virtual private network (VPN), intranet or othersuitable network system and includes equipment for receiving andtransmitting signals.

If the computer 101 is a PC, workstation, intelligent device or thelike, the instructions in the memory 110 may further include a basicinput output system (BIOS) (omitted for simplicity). The BIOS is a setof essential routines that initialize and test hardware at startup,start the OS 111, and support the transfer of data among the hardwaredevices. The BIOS is stored in ROM so that the BIOS can be executed whenthe computer 101 is activated. When the computer 101 is in operation,the processor 105 is configured to execute instructions stored withinthe memory 110, to communicate data to and from the memory 110, and togenerally control operations of the computer 101 pursuant to theinstructions.

In exemplary embodiments, the computer 101 further includes a softwareinterface 180 that is configured to communicate with a streaminghardware device 185. The streaming hardware device 185 is a deviceconfigured to perform a data manipulation function, which can be anyalgorithm that manipulates input data into a defined format of outputdata. In exemplary embodiments, the data manipulation function mayincrease or decrease the size of the input data. For example, the datamanipulation function may be configured to compress or decompress data.In exemplary embodiments, the operating system 111 includes a libraryAPI 175, which is a software library comprising APIs for performing thedata manipulation functions provided by the streaming hardware devices185.

In exemplary embodiments, the library API 175 is configured to determineif a request for a data manipulation function will be executed by asoftware API or by the streaming hardware device 185. The library API175 may make this determination based on the size of the data to bemanipulated, the availability of the streaming hardware device 185 andcharacteristics of the streaming hardware device 185. In exemplaryembodiments, the availability and characteristics of the streaminghardware device 185 can be provided to the library API 175 by thesoftware interface 180. For example, the software interface 180 mayprovide the library API 175 with a suggested minimum data size for theuse of the streaming hardware device 185 based on the overheadassociated with using the streaming hardware device 185.

In exemplary embodiments, the software interface 180 is configured toprovide buffering support for data manipulation requests received fromand responses sent to the library API 175. In exemplary embodiments, thesoftware interface 180 can also provide fail-over processing in theevent of a failure of the streaming hardware device 185.

In exemplary embodiments, the software interface 180 may be configuredto determine if data manipulation requests received from the library API175 are viable to be sent to streaming hardware device 185. Theviability of a data manipulation request can be based on determining ifthe overhead of performing the setup for sending the operation to thestreaming hardware devices 185 outweighs the cost of doing the operationitself. If this goal can not be reached it would be more efficient toperform the data manipulation request using the software API equivalentto the streaming hardware device 185. In exemplary embodiments, thesoftware interface 180 provides the library API 175 with a minimumthreshold size that represents the lower bound size of viability for adata manipulation request.

In exemplary embodiments, the streaming hardware device 185 isconfigured manipulate input data such that the when the output of therequest is provided as input the original input data is generated (i.e.,the operation of the streaming hardware device 185 is reversible). Thesoftware interface gives the streaming hardware device 185 both the datato manipulated and control data. The control data is used to helprestore the original data at the point in time when the datamanipulation is reversed. A complete stream of data manipulated by thestreaming hardware device 185 is shown in FIG. 3A.

Both the control data and the manipulated data are bits strings that maynot be byte aligned. Because the streaming hardware device 185 can onlyput full bytes in the output stream, when the streaming hardware device185 completes a request, the last bits it produced may not make up afull byte. These bits are returned as extra data to the softwareinterface 180. One the next request from the library API 175, thesoftware interface 180 appends any new control data to the extra datafrom the last request. If the results of appending the new control dataand the extra data from the last request is less than a byte in length,the results are passed to the streaming hardware device 185 in aparameter call insert_bits. If the result is longer than 1 byte, thesoftware interface 180 directly puts the full bytes in the output streamand passes any bits beyond the last full byte to the streaming hardwaredevice 185 in a parameter called insert_bits.

In exemplary embodiments, the streaming hardware device 185 may beconfigured to partially process input data and provide partial outputbased on that subset of input data by saving state information that canbe restored on subsequent calls.

Referring now to FIG. 2, a block diagram illustrating a system 200 fortesting a software interface 204 for use with a streaming hardwaredevice in accordance with an exemplary embodiment is shown. Asillustrated, the system 200 includes a library API 202, a softwareinterface 204 and a simulation device 206. In exemplary embodiments, thelibrary API 202 is configured to receive a request from an applicationto perform a data manipulation function and to pass the request to anappropriate software interface 204. The software interface 204 isconfigured to interface with a simulation device 206, which isconfigured to simulate the operation of a streaming hardware device byoperating on a bit stream received from the software interface 204.

In exemplary embodiments, the simulation device 206 is designed topresent the same interface to the software interface 204 as thestreaming hardware device would. The software interface 204 functionsthe same way when calling the simulation device 206 as it would whencalling the streaming hardware device. The fact that use of thesimulation device 206 is transparent to the software interface 204,allows the simulation device 206 to be used to test that the softwareinterface is properly interacting with a real streaming hardware device.

In exemplary embodiments, the simulation device 206 is configured tomanipulate input data in such a way that automated test cases can beused to determine that software interface 204 has correctly injectedcontrol information into the data stream provided to the simulationdevice 206. In addition, the simulation device 206 may be configured toperform checks to insure that the software interface 204 is providingthe correct data to the simulation device 206 during the processingdata.

In exemplary embodiments, the simulation device 206 includes datamanipulation logic that is configured to allow injection of control databy the software interface 204. In one embodiment, the simulation device206 may designate a delineator that is used to delineate data to bemanipulated from control data. In exemplary embodiments, the delineatormay be a value less than eight bits.

When software interface 204 calls the simulation device 206 for thefirst request in a stream, it will pass the application data for therequest, the length of the application data for the request, and controldata in the insert_bits parameter. In response, the simulation device206 will generate an output stream as shown in FIG. 3B.

When the simulation device 206 returns data to the software interface204, the simulation device 206 passes the delineator back to thesoftware interface 204 as extra data. The software interface 204 isunaware that a delineator has been returned in the extra data and itprocesses the extra data as if it was interfacing with a real streaminghardware device. For each request received, the software interfacedecides whether or not to add control data to the data stream.

In cases where the software interface 204 does not add additionalcontrol data to the stream received from the simulation device 206. Inthe next request from the library API 202, the software interface 204will pass the extra data returned from the previous request in theinsert_bits parameter for the new request. Additionally, the softwareinterface 204 will pass the application data and the length of theapplication data. The results of the simulation device 206 processingthe request will be an output stream as shown in FIG. 3C. As shown inFIG. 3C, the delineator is added to the output stream since it waspassed to the simulation device 206 in the inserts bits parameter.

In cases where the software interface 204 does need to add control datato the stream to the stream received from the simulation device 206. Thesoftware interface 204 will append the extra data returned from thesimulation device 206 to the new control data. The software interface204 will then add the full bytes, if any, resulting from this append tothe output stream, which results in an output stream as shown in FIG.3D. As shown in FIG. 3D, the delineator is added to the output streamsince it was contained in the extra data returned from the simulationdevice 206.

In exemplary embodiments, the delineator and the beginning of thecontrol data may share a byte and any bits beyond the last full bytewritten to the output stream are kept until the next request from thelibrary API 202. When the library API 202 calls the software interface204 for the next request, the software interface 204 passes theremaining bits from the last request in the insert_bits parameter to thesimulation device 204. These remaining bits contain the last piece ofcontrol data. Additionally, the new application data and its length arepassed to the simulation device 204. As a result of the processing ofboth the software interface 202 and the simulation device 204, an outputstream as shown in FIG. 3E is provided.

The simulation device 204 inserts the piece of control data that waspassed to it in the insert_bits field. Because the insert_bits field wasnot equal to the delineator, it then inserts a delineator. Finally itinserts the length of the application data and the application data.

In exemplary embodiments, since the application data and the controldata is segregated with the delineators test applications canpost-process the output stream to insure that control informationinjected by the software interface is correct.

Referring now to FIG. 4, a flow diagram illustrating a method 400 fortesting a software interface for a streaming hardware device throughsimulation is shown. As shown at block 402, the method 400 includesreceiving a data manipulation request and associated data. Next, asshown at block 404, the method 400 includes transmitting the input datastream to a simulation device. As shown at block 406, the method 400includes generating an output data stream in response to the input datastream, the output data stream including the delineator, manipulateddata and a trailing delineator. In exemplary embodiments, the method 400may include appending control information and/or software interfacecontrol information to the output stream, as shown at block 408.

In exemplary embodiments, the output data stream may not include enoughinformation to restore a segment of manipulated data, which may impactthe ability to perform processing to verify the proper operation of thesoftware interface. Accordingly, the simulation device may be configuredto save state information between calls from the software interface.

In exemplary embodiments, the simulation device is also configured toreceive an output data stream of the simulation device and to generatean input data stream that would have created the output data stream.

Referring now to FIG. 5, a state diagram illustrating the operation of asimulation device is shown. As illustrated, the simulation device canoperate in a plurality of states including, a request state 502, adelineator state 504 or a processing state 506. In the request state502, the simulation device is awaiting a request from a softwareinterface. Once the simulation device receives a request, and associateddata, from a software interface, the simulation device will verify thatthe request is valid and proceed to the delineator state 504. In thedelineator state 504, the simulation device will determine theappropriate delineator and then proceed to the processing state 506. Atthe processing state 506, the simulation device processes the next byteof data and determines if the byte of data is equal to the delineator.If the byte of data is equal to the delineator, the simulation devicereturns to the delineator state 504. Otherwise, the byte is processed, abytes processed variable is incremented, and the simulation device staysin the processing state 506 and continues by processing the next byte.If during the delineator state 504, the simulation device determinesthat then end of the data block has been reached, the simulation devicereturns to the request state 502. In exemplary embodiments, thesimulation device may determine that the end of the data block has beenreached by comparing the bytes processed variable with a length variablethat is indicative of the number of bytes to be processed by therequest.

In exemplary embodiments, if the end of the data is reached during theprocessing state 506 the total length of the data and current length, ornumber of bytes processed, are saved along with an indication that endof the data was reached in the processing state 506. In exemplaryembodiment, as delineators indicating the end of a data segment areencountered the bytes processed count will be validated against thesegment length to insure that all data is accounted for during therestoration.

As will be appreciated by one skilled in the art, aspects of the presentinvention may be embodied as a system, method or computer programproduct. Accordingly, aspects of the present invention may take the formof an entirely hardware embodiment, an entirely software embodiment(including firmware, resident software, micro-code, etc.) or anembodiment combining software and hardware aspects that may allgenerally be referred to herein as a “circuit,” “module” or “system.”Furthermore, aspects of the present invention may take the form of acomputer program product embodied in one or more computer readablemedium(s) having computer readable program code embodied thereon.

Any combination of one or more computer readable medium(s) may beutilized. The computer readable medium may be a computer readable signalmedium or a computer readable storage medium. A computer readablestorage medium may be, for example, but not limited to, an electronic,magnetic, optical, electromagnetic, infrared, or semiconductor system,apparatus, or device, or any suitable combination of the foregoing. Morespecific examples (a non-exhaustive list) of the computer readablestorage medium would include the following: an electrical connectionhaving one or more wires, a portable computer diskette, a hard disk, arandom access memory (RAM), a read-only memory (ROM), an erasableprogrammable read-only memory (EPROM or Flash memory), an optical fiber,a portable compact disc read-only memory (CD-ROM), an optical storagedevice, a magnetic storage device, or any suitable combination of theforegoing. In the context of this document, a computer readable storagemedium may be any tangible medium that can contain, or store a programfor use by or in connection with an instruction execution system,apparatus, or device.

A computer readable signal medium may include a propagated data signalwith computer readable program code embodied therein, for example, inbaseband or as part of a carrier wave. Such a propagated signal may takeany of a variety of forms, including, but not limited to,electro-magnetic, optical, or any suitable combination thereof. Acomputer readable signal medium may be any computer readable medium thatis not a computer readable storage medium and that can communicate,propagate, or transport a program for use by or in connection with aninstruction execution system, apparatus, or device.

Program code embodied on a computer readable medium may be transmittedusing any appropriate medium, including but not limited to wireless,wireline, optical fiber cable, RF, etc., or any suitable combination ofthe foregoing.

Computer program code for carrying out operations for aspects of thepresent invention may be written in any combination of one or moreprogramming languages, including an object oriented programming languagesuch as Java, Smalltalk, C++ or the like and conventional proceduralprogramming languages, such as the “C” programming language or similarprogramming languages. The program code may execute entirely on theuser's computer, partly on the user's computer, as a stand-alonesoftware package, partly on the user's computer and partly on a remotecomputer or entirely on the remote computer or server. In the latterscenario, the remote computer may be connected to the user's computerthrough any type of network, including a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

Aspects of the present invention are described below with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems) and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer program instructions. These computer program instructions maybe provided to a processor of a general purpose computer, specialpurpose computer, or other programmable data processing apparatus toproduce a machine, such that the instructions, which execute via theprocessor of the computer or other programmable data processingapparatus, create means for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

These computer program instructions may also be stored in a computerreadable medium that can direct a computer, other programmable dataprocessing apparatus, or other devices to function in a particularmanner, such that the instructions stored in the computer readablemedium produce an article of manufacture including instructions whichimplement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer,other programmable data processing apparatus, or other devices to causea series of operational steps to be performed on the computer, otherprogrammable apparatus or other devices to produce a computerimplemented process such that the instructions which execute on thecomputer or other programmable apparatus provide processes forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of onemore other features, integers, steps, operations, element components,and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

The flow diagrams depicted herein are just one example. There may bemany variations to this diagram or the steps (or operations) describedtherein without departing from the spirit of the invention. Forinstance, the steps may be performed in a differing order or steps maybe added, deleted or modified. All of these variations are considered apart of the claimed invention.

While the preferred embodiment to the invention had been described, itwill be understood that those skilled in the art, both now and in thefuture, may make various improvements and enhancements which fall withinthe scope of the claims which follow. These claims should be construedto maintain the proper protection for the invention first described.

What is claimed is:
 1. A computer system for testing a softwareinterface for a streaming hardware device through simulation, thecomputer system comprising: a processor that performs a methodcomprising: receiving a data manipulation request and a data segmentassociated with the data manipulation request; generating, by thesoftware interface, an input data stream comprising control informationand the data segment, wherein the input data stream includes a lengthfield and a delineator, wherein the length field consists of the size ofthe data segment associated with the data manipulation request;transmitting the input data stream to a simulation device; saving stateinformation between calls from the software interface, wherein the stateinformation is saved by the simulation device; generating, by thesimulation device, an output data stream in response to the input datastream, by inserting a second delineator, a second control data, and amanipulated data segment, wherein the manipulated data segment and thecontrol data are separated by the second delineator; storing the outputdata stream, by the simulation device, wherein the simulation devicesimulates the operation of the streaming hardware device by performingthe data manipulation request; and verifying whether the softwareinterface functions properly, by performing the steps of: transmittingthe output data stream to a simulation device; processing the outputstream by a test application to insure, using automated test cases, thatthe software interface has correctly inserted the control data into theoutput data stream; further in response to receiving the output datastream, generating, by the simulation device, a restored data segmentbased on the inserted second control data and saved state information;and determining whether the restored data segment is identical to thedata segment to thereby indicate the proper operation of the softwareinterface.
 2. The computer system of claim 1, further comprisingappending software interface control information to the output stream.3. The computer system of claim 1, wherein the output data streamincludes the control information.
 4. The computer system of claim 1,wherein the control information is a series of bits that will not impactthe data segment of the input data stream or output data stream.
 5. Thecomputer system of claim 1, wherein the simulation device is configuredto process a portion of the input data stream and to generate a partialoutput data stream based on the portion of the input data stream and tosave state information that can be restored on subsequent calls to thesimulation device.
 6. The computer system of claim 1, wherein thesimulation device is configured save state information between callsfrom the software interface, wherein the state information can be usedby the test application to insure that the software interface hascorrectly inserted the control data into the output data stream.